Subject: Alternate DLSw transports

From: "Steve Klein" <[email-masked]>
Date: Mon, 10 Jul 95 10:51:33 EDT

Hello all.  Time to get some discussion moving on alternate transports
for DLSw.  One proposal was LLC2.  I had in my notes from the last AIW
that Jim Cobban was going to make a proposal.  Jim, is that true?

I was also wondering if one of the Cisco people could post the frame
format for there LLC over Frame Relay transport.  Is it based on FRF.3?

Steve

---

From: "jim (j.) cobban" <[email-masked]>
Date: Tue, 11 Jul 1995 11:55:00 -0400

>format for there LLC over Frame Relay transport.  Is it based on FRF.3?

The question of the use of LLC2 as a transport layer is being discussed in
the ISO under the topics Transport Layer Fast Byte (DIS 14699) and Network
Layer Fast Byte (DIS 14700).  The concept which is espoused in these
standards is that there are many implementations in which a reliable data
link layer is imbedded in the hardware, and therefore runs faster than any
software implementation at a higher layer.  There are also applications in
which the functions provided by the network and transport layers, such as
multiplexing and segmentation, are unnecessary.  These draft specifications
describe how the transport service semantics are mapped directly to network
service semantics in a null transport layer, and how the network service
semantics are mapped to data link service semantics in a null network layer.

This work is directly applicable to DLSw, which expects the availability of
certain transport semantics.

If DLSw is to use a reliable data link layer there are several issues to
identify.

Protocol Identification
-----------------------
How is DLSw transport traffic distinguished from other traffic on the same
shared medium?  This must bear in mind the protocol identification
capabilities provided by the various data link implementations.

- on X.25 we could agree on a protocol identifier to use in the first
  byte of the call user data.  This is a rather crowded address space so
  a better option would be to use X'80' as the protocol id, and then use
  the IEEE Subnetwork Access Protocol (SNAP) for protocol identification
  within the call user data.  Related closely to this is using protocol id
  X'00' which signals the use of SNAP headers in each contained data packet
  to permit sharing a single virtual circuit among multiple protocols.
  These options are discussed in RFC 1356.  If a SNAP encapsulation is
  preferred then the AIW should obtain, if it does not already have, an
  Organizational Unique Identifier (OUI) within which to assign a
  protocol identifier.

- on LLC2 there is only the service access point (SAP) index available
  for protocol identification.  This is an extremely crowded address
  space and there is no formal mechanism for reserving individual SAPs
  for use by particular protocols except those recognized by the IEEE
  and ISO.  One option therefore is to specify a default SAP for DLSw
  transport and require that it be overrideable by provisioning.
  Perhaps a better alternative is to use the reserved SAP for SNAP
  protocol identification X'AA'.  Then the same protocol identification
  as was suggested for X.25 could be used.  The only awkwardness with
  this is that I do not believe that SNAP identification has ever been
  used for a protocol which expects reliability from the lower layer.
  For example SNA uses a SNAP identifier on Ethernet, but this SNAP
  identifier indicates that LLC2 is imbedded in the PDU.  This suggests two
  different protocol identifiers, one which indicates that reliability is
  expected from the lower layer, and one which provides it itself by
  including an LLC2 header in the PDU.

- on Ethernet, where LLC2 is not normally available, a SNAP encapsulation
  makes sense, except that the protocol identifiier which indicates that
  the PDU includes LLC2 is required.

- on Frame-Relay using RFC 1490 encapsulation it seems reasonable to
  use the same Q.933 (NLPID X'08') encapsulation used by the other
  protocols (SNA and NetBIOS) which depend upon a reliable data link
  layer.  If this is done the AIW would  register another
  layer 3 protocol identifier, say X'7086', as identifying the DLSw
  transport layer.  Another alternative is to use the SNAP protocol
  identification (NLPID = X'80') however as with LANs this has never
  been used with the multiple acknowledgement subset of LAPF (equivalent
  to LLC2), although the RFC1490 formats do reserve space for expanding
  the control field to the two bytes required for I and S frames.  The
  same encapsulation should be used over ATM (RFC 1483).  Cisco may
  suggest some alternatives based upon their practical experience.

- on serial links PPP would appear to be the protocol of choice for
  multiprotocol identification.  There are already several protocols
  which require reliable data link layers which have PPP protocol
  identifiers for example NetBIOS (X'003F'), SNA over LLC2 (X'004B') and
  SNA (X'004D').  It is normally required that if an individual protocol
  requires reliable transmission over PPP that that reliability be
  ensured by the individual transport protocol.  PPP provides reliable
  transmission only for the purpose of ensuring the integrity
  of compression dictionaries.  Therefore it is proposed that the AIW
  register PPP protocol identifiers for DLSw over LLC2 and the
  associated control protocol.

In summary, the conclusion that I come to is that on all media, except
serial links using PPP, the use of LLC2 as a transport by DLSw should be
identified by means of SNAP protocol identification.  The AIW should
have an OUI and assign two protocol ids under this: DLSw assuming that
the base DLC provides a reliable data link layer, and DLSw with LLC2 to
recover from an underlying data link which does not provide reliability.

Discovery
---------
If LLC2 is used on a broadcast medium it makes sense to have a mechanism to
discover the peers on the same medium.  There are a number of effective
techniques which have been used for this.  One option is to register a
multicast address for DLSw discovery.  The format and registry for such a
multicast address will be media dependent.  When a new DLSw joins a shared
medium it would send a frame (UI makes sense to me) to the multicast address.
This frame would be received by the existing peers, each of which would
respond, if appropriately configured, by establishing a transport connection
back to the new peer.  In order to ensure complete connectivity is possible a
new subvector on the capabilities exchange would be used to carry a list
of all MAC addresses of stations on the shared medium that the
initiating station is aware of.  This would deal with the possibility of
the UI not being received by all of the peers.  If sending this
discovery frame did not initiate any responses then the new DLSw would
retransmit it after a time-out.  This could be quite long because the
most probable reason for no response is that this switch is the very
first to join this shared medium.  In that case it will be notified as
soon as any other peer joins.

References:
-----------

 [1] RFC 1042 "Standard for the transmission of IP datagrams over IEEE 802
     networks"

 [2] RFC 1356 "Multiprotocol Interconnect on X.25 and ISDN in the Packet
     Mode"

 [3] RFC 1483 "Multiprotocol Encapsulation over ATM Adaptation Layer 5"

 [4] RFC 1490 "Multiprotocol Interconnect over Frame Relay"

 [5] RFC 1661 "The Point-to-Point Protocol (PPP)"

 [6] RFC 1700 "ASSIGNED NUMBERS"

 [7] DIS 14699 "Transport Layer Fast Byte"
 
 [8] DIS 14700 "Network Layer Fast Byte"